Network operators typically test network nodes for reliability and other characteristics before deploying the network nodes in live (e.g., non-test) and/or protected networks, e.g., private networks protected by one or more security related devices, such as a firewall and/or a network address translator (firewall/NAT). While testing a network node before deployment may be beneficial, scenarios exist where testing a network node in a live and/or protected network is useful and/or necessary, e.g., for detecting and/or resolving previously undetected issues. However, issues can arise when attempting to configure network nodes for testing in a live and/or protected network. In particular, configuring network nodes for testing in a live and/or protected network may create or exacerbate security concerns since a test operator may need to traverse a firewall/NAT to communicate with the network nodes.
Traffic related measurements, such as one way delay, jitter, mean opinion score (MOS), are typically dependent on clock synchronization between two endpoints, e.g., a sender and a receiver. Conventional techniques for synchronizing clocks in a live and/or protected network involve using external sources for synchronization, such as a global positioning system (GPS) or a network time protocol (NTP) server. However, these techniques can have significant drawbacks or issues. For example, deployment can be tedious and errors prone because such techniques generally require significant modifications to the endpoints and/or network architecture. Further, when using a public NTP server to synchronize, such techniques may yield a lack of precision because the round-trip time required to synchronize endpoints' clocks with the NTP server will be doubled compared to a scenario where the endpoints communicate directly.
Accordingly, a need exists for improved methods, systems, and computer readable media for receiving a clock synchronization message.